Fixed halt reason after single-step#618
Conversation
After single step operation, we should not assume that the halt reason is single-step. There can be a higher-priority halt cause, e.g. a breakpoint. The real halt reason should be obtained from the target (dcsr.cause).
timsifive
left a comment
timsifive
left a comment
There was a problem hiding this comment.
That looks right. What testing have you done for this? I'm concerned with some weird case where gdb doesn't work right because it expects that state to be single stepped after issuing that.
I've tested this internally against the LLDB debugger (which speaks the GDB Remote protocol, same as GDB). Without the patch, the debugger did not report a watchpoint hit during single-stepping to the user. For GDB, I need to run |
|
Assuming e.g. all the spike32-2 tests from riscv-tests/debug pass then I'm fine merging this. |
I've run the riscv-tests on this change here: JanMatCodasip#3 I still believe reporting the real halt cause to the debugger when stepping is correct approach, yet this change is not sufficient as is and something else needs to be updated as well. |
|
Closing this outdated merge request. The main problem appears to be that |
2 participants
After single step operation, we should not assume that the halt
reason is single-step. There can be a higher-priority halt cause,
e.g. a breakpoint.
The real halt reason should be obtained from the target (dcsr.cause).